It is known practice for an operator to use content distribution networks for distributing content in a communication network. Generally, these networks comprise source entities and sink entities for replicated content, subsequently called entities for distributing a content. The source entities provide content that are duplicated according to their popularity, for example, on sink entities situated close to the recipients of this content. They thus allow the source entities not to be called upon and forwarding costs to be decreased.
In order to guarantee the integrity and the origin of a content, it is likewise known practice for an operator to implement a secure interchange protocol, such as the HTTPS (HyperText Transfer Protocol Secure) protocol, in a content distribution network. The latter protocol allows security to be provided for HTTP (HyperText Transfer Protocol) interchanges by means of an SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocol layer for providing security for interchanged data. The SSL/TLS layer primarily performs three roles:                authenticate the entities taking part in the interchange,        ensure the confidentiality of interchanged data,        guarantee the integrity of interchanged data.        
The authentication allows the identity of the entities taking part in the interchange to be guaranteed. It is implemented by means of certificates issued by a certification authority, which allow the identity of an entity to be proved to a third-party entity. A relationship of trust can thus be established between the entity for which a certificate has been issued and the third-party entity which needs to communicate with said entity.
The SSL and TLS protocols, and more particularly the SSL/TLS negotiation (Handshake protocol), are described in the document Request for Comments 6101 and 5246 from the IETF (Internet Engineering Task Force). This negotiation consists, for two entities wishing to establish secure communication, in negotiating common keys and encryption protocols, allowing their interchanges to be encrypted. For this, the two entities, the client and the server, first of all interchange a Hello message in order to agree on the authentication and encryption algorithms that they will use. The server entity then sends its certificate to the client entity. This certificate contains information about the entity that holds it, information associated with the authority that has issued it (name of the authority, validity of the certificate, etc.), a public encryption key and a signature. The server entity has a private key associated with the certificate. The client entity checks the authenticity of the certificate and the integrity of the server entity by means of the public encryption key and the signature of the certificate. The client entity then produces a generation key, called “premaster secret”, which it transmits to the server entity, encrypted using the public encryption key. The server entity decrypts the received generation key by means of the private key associated with the certificate. From this generation key, the client and server entities generate one or more common session keys that allow their interchanges to be provided with security.
The method for setting up a secure session as provided for in RFC 5246 and 6101 thus requires access to the private key that is known only to the entity for which a certificate has been issued. It is possible for a certified source entity providing a content to delegate the distribution of said content to distribution entities of a content distribution network. In this case, the certificate of the certified entity and the private key must be provided for the content distribution network. The latter, which is the custodian of the content to be distributed, can thus distribute it transparently to the entity that requires it. It may be advantageous for this proxy content distribution network to itself turn to another content distribution network. This allows the proxy network to benefit from the proximity of the entities for distributing a content of the third-party content distribution network vis-à-vis the recipients of this content. However, within a secure interchange context, it is generally prohibited for the content distribution network having obtained authorization for a certified entity to communicate the private key to a third party. In the prior art, it is thus impossible for a third-party distribution network keeping a content to be distributed to distribute it in a secure manner to an entity that requires it if it does not have the private key associated with the certified entity. The identity of the certified entity and the integrity of the content therefore cannot be guaranteed, the effect of which is that it is not possible to establish a relationship of trust between the entity requiring the content and the third-party distribution network that is the custodian thereof.